Certificate components

Certain connectors and document types might require the use of a certificate to ensure security when transmitting data across the communication protocol. Connectors such as FTPS, SFTP, HTTPS, AS2, and many others require certificates to encrypt data and channels and to verify the digital signature of the person sending the data.

Certificates might use an existing key obtained from a certificate authority such as Verisign or Thawte, or use a key generated by Boomi. Keys generated by Boomi are no less secure than purchased certificates.

There are two types of certificates:

• Certificate authority certificates, or CA certificates, are not components. You manually import them into Runtime’s trust store using the keytool utility. By default, the trust store is the cacerts file in the Runtime’s jre/lib/security/cacerts directory. The location of your Runtime’s trust store might be different.

• Boomi certificates, or user certificates, on the other hand, are wrapped within components. You create these components on the Build page. Creating Boomi certificates means that you self-sign the certificate. This is important to keep in mind when using a Boomi certificate with a third-party service.

You can create two types of Boomi certificates: X.509 and PGP. A certificate can be public or private.

• A public certificate contains only a public key. If you open a public certificate, you can import another public certificate into it and export its public key.

• A private certificate contains both public and private keys. If you open a private certificate, you can import another private certificate into it and export its private and public keys.

If you open a private certificate you can:

• Import another private certificate into it

• Export its private and public keys.

If you open a public certificate you can:

• Import another public certificate into it

• Export its public key.

Private and public certificate file names have different file extensions.

Certificate type	File extension(s)
Public X.509	.cer or .der
Private X.509	.pfx or .p12
Public PGP	_pub.asc
Private PGP	_priv.asc

note

Check the documentation about the specific connector that you are using for more information about its specific certificate usage.

Creating and importing certificates

You can create and import certificates in the following ways:

• You can create a certificate and generate a private key for it.

• When you create a certificate, you can import an existing private or public certificate into it. If you import a private certificate, your new certificate is private. If you import a public certificate, your new certificate is public.

• For a private X.509 certificate, you can import a chain of certificates. Information about each certificate in the chain is displayed in the Certificate tab.

• For a PGP certificate, you can define process extensions to enable different certificates to be substituted when a process is deployed.

note

Imported certificates are first passed through a virus scanner. The import results in an error if a virus is detected, and the certificate is rejected. If an error persists, contact Boomi Support.

Modifying and exporting certificates

After creating a Boomi certificate, you can modify or export certain aspects of the certificate depending on its type.

• You can change the name of a public or private certificate that you created.

• For private certificates, you can:

  • Re-import a private certificate or regenerate the private key. This action overwrites the current certificate, saving you from the trouble of creating a new certificate and changing any process components to reference the new certificate. This approach is very useful when you have to replace expired certificates.

  • Export the public and/or private keys for a private certificate. Exported private keys are password protected with the password of your choice.

  • Change the password for a private X.509 certificate, provided that you have its current credentials. If the password is not encrypted and you attempt to close the X.509 certificate without saving it, you see a message that prompts you to re-save the certificate.

• For public certificates, you can:

  • Re-import a public certificate, which is similar to re-importing a private certificate. You cannot generate a new key for a public certificate.

  • Export only the public key for a public certificate. You might want to export a public key to give to your trading partner (or other client application) to encrypt the data that they send you.

Deploying Certificate components independently

note

Public X.509 and public PGP certificates are the only type of Certificate components that you can deploy independently.

When a process is deployed to a Runtime or environment, dependent Certificate components referenced in Connector steps in the process are deployed, along with all other dependent components. If a certificate deployed in this manner expired and you secured a replacement, you would need to revise all of the processes for which the expired certificate is a dependent component to use the replacement certificate. Then you would need to redeploy those processes.

A better approach, which is valid only for public X.509 certificate components, is to deploy Certificate components independently to Runtimes or environments. You can do this on the Deployments page (or the Deploy page for Legacy deployment). When a Certificate component is deployed independently, the certificate is loaded into the Runtime’s trust store and thus implicitly trusted by all connections that do not otherwise specify a custom SSL context.

A connection’s Use Trusted SSL Certificate option overrides deployed Certificate components. For example, suppose your web server is running with Certificate component A, and that component is deployed to your Runtime. If in a deployed process the connection is configured with the Use Trusted SSL Certificate option to use Certificate component B, when the process is executed, certificate B will be used for the SSL connection and the connection will fail.